It should be recalled that on an international scale the format of public telephone numbers is defined by Recommendation E.164 of the ITU-T, where the ITU-T is a portion of the International Telecommunication Union (ITU) responsible for developing international standards.
It should also be recalled that IP networks can carry conversation services such as “voice over IP” (VoIP), “content sharing”, or “instant messaging”. Nowadays IP networks are generally suitable for performing advanced session control protocols such as H.323 or SIP.
The label H.323 covers a set of audiovisual communication protocols in an IP network, which protocols were developed by the ITU-T. They relate to signaling, negotiating data-coding parameters, and transporting data. They are widely used in VoIP and in video conferences, and also in several real time Internet applications such as “NetMeeting”.
The session initiation protocol (SIP) was defined by the Internet engineering task force (IETF) in Document RFC 3261. That protocol makes it possible to set up, modify, and terminate multimedia sessions in a network using IP.
SIP is used in particular in infrastructures of the IP multimedia subsystem (IMS) type. IMS is defined by the third generation partnership project (3GPP) standards organization. That network architecture, which is applicable both to mobile and to fixed access networks, enables multimedia sessions to be set up dynamically and to be controlled between two clients and also enables resources to be reserved in the network for transporting multimedia streams. By means of this architecture, network operators can conveniently implement a management policy, provide a predetermined quality of service (QoS), and calculate how much to bill clients. At present, IMS makes it possible to access services of the telephone, video phone, presence, and instant messaging types, and it also manages interaction between them.
Communications services over IP networks can identify physical or virtual resources by means of character strings, e.g. an H.323 alias or a universal resource identifier (URI). The syntax of URIs is defined by IETF Document RFC 3986; knowing the URI of a resource makes it possible to obtain the IP address of a piece of equipment in the network of the operator managing that resource.
In particular, in networks that use SIP, a distinction is drawn between two types of resource identifier: those in the “SIP-URI” form as defined in RFC 3261, and those of the “tel-URI” form as defined in RFC 3966. An SIP-URI is of the form “sip:user@host” (e.g. sip:alice@domain1), where the “host” part identifies the domain of the operator responsible for the identity represented by the “user” part. A tel-URI is of the form “tel:telephone_number” (e.g. tel:+33123456789) which refers to international public telephone numbers, or of the form “tel:telephone_number:phone-context= . . . ” (e.g. tel:0623456789;phone-context=+33) with reference to telephone numbers in a format that is valid only in a narrower context (in this example the 10-digit number format 0623456789 is valid only within the French numbering plan).
For reasons of brevity, throughout the remainder of the present description, the term “URI” is used for any type of physical or virtual application resource that is accessible on a network.
It should also be recalled that the domain name system (DNS) is a service that enables information to be found starting from a domain name. DNS servers make associations of a domain name with information of a certain type, known as resource records, available to any client computer (“DNS resolver”) that has issued a DNS request. In particular, naming authority pointer resource records (NAPTR) as described in RFC 3402 specify substitution rules for application to a character string in order to produce a certain result, such as in particular another domain name or a URI. The DNS system, on the basis of NAPTRs, thus makes it possible to match one character string with another by searching for a domain name: by applying a rule specific to the application in question, it suffices to transform the original character string into a domain name that is to be associated with a substitution rule for application to the original string in order to produce the looked-for result.
In order to be able to set up a call via one or more networks, the network/domain to which the caller belongs and referred to below as the “originating” domain, must therefore know the identity of the network/domain, that makes it possible to reach the called user and that is referred to below as the “destination domain”. However, the caller often knows only the telephone number of called user, which telephone number is in the public format specified in Recommendation E.164 or in a private format. Unfortunately, the telephone number does not make it easy to determine the identity of the destination domain; in other words, there is no automatic association between the E.164 identifier and the URI (or URIs) for entry into the destination domain. In this respect, it may be observed that a domain may possesses a plurality of entry URIs, which may also possibly be a function of the identity of the calling domain; for reasons of brevity, in the present document, the term “URI of the destination domain” is sometimes used to mean the entry URI(s) of that domain.
Furthermore, it is generally not possible to identify the destination domain from the structure of the telephone number (e.g. its initial digits), since it is not known a priori whether the telephone number in question has or has not been “ported”. In this respect, it should be recalled that the term “number portability” refers to changing the operator or the domain that hosts the user associated with that telephone number.
In order to solve this problem, in a first known technique, the originating domain routes calls on the basis of telephone number ranges, in a manner analogous to the routing performed in the public-switched telephone network (PSTN) or in mobile switched networks such as the public land mobile network (PLMN). However such routing is expensive in terms of operational management (initial configuration, plus modifications if any). Furthermore, in particular with international calls, the originating domain has only partial knowledge about the way the numbering plan is managed in the destination country, which can make intermediaries necessary and can prevent a direct connection being established between the originating domain and the destination domain. This type of solution requires dedicated processing that cannot be shared with the processing used for routing alphanumeric URIs, i.e. URIs in which the “user” component (such as “alice” in sip:alice@domain1) is not a telephone number, said routing using the “host” component of the URI (i.e. “domain1” in sip:alice@domain1).
In a second known technique, the originating domain implements a telephone number mapping (also known as tElephony NUmbering Mapping) (ENUM) application. The ENUM application uses a database specific to the network to which the originating domain belongs and containing particular NAPTRs defined in RFC 3761. By means of a DNS request using an interrogation key (as described above) representative of a telephone number in E.164 format, the ENUM application makes it possible to discover the URIs that can be used for reaching a called party. These URIs point to resources or services associated with the E.164 number of the called party, such as for example an email address, a web page, a directory service, fixed or mobile transfer numbers, or a VoIP, video phone or instant messaging alias for SIP or H.323 protocols.
In practice, two situations can arise when interrogating an ENUM database.
In the first situation, the interrogation key is indeed present in the ENUM database and the corresponding NAPTR gives the value “u” to a parameter called “Flags” (as specified in RFC 3761). This value “u” indicates that the ENUM request is “terminal” in the sense that the response to the request gives directly one or more URIs for the called party (when there are several URIs, the response also gives a recommendation as to the order in which they should be processed).
In the second situation, the interrogation key does not appear in the ENUM database. Under such circumstances, routing cannot be performed using the above-described mechanism, but, inconveniently, requires the operator of the network to set up an ad hoc mechanism that is dedicated to known telephone numbers. This ad hoc mechanism varies from one operator to another and can make methods of analyzing numbers in call servers more complex, or it can define a route by default, e.g. requiring transit via the public-switched telephone network PSTN.
It is necessary to have recourse to such an ad hoc mechanism in particular when the telephone number has been ported, as mentioned above. Ad hoc functions must then be developed to incorporate in standard routing mechanisms the ability to detect that the number has been ported from one network or domain to another. Without that, a call to a number that has previously been ported from one network or domain to another network or domain would fail.
This problem of portability relates to any type of telephone call, i.e. any operation seeking to set up a network session (VoIP, video conference, instant messaging, etc.) that makes use of this “called” telephone number. More generally, the problem relates to any message of a session control protocol (e.g. SIP or H.323) using a telephone number as a routing identifier, regardless of the purpose of the message, e.g. setting up a telephone call, opening a session, subscribing to the state of a resource (a SIP SUBSCRIBE message), or requesting the capacity of a resource (SIP OPTIONS message). The “user” associated with a telephone number acting as a routing identifier may be a human being or a machine (e.g. a telephone answering machine), or it could equally well be a service, which service was initially hosted on a first operator domain and has since been ported to a second operator domain.
One solution to this problem could consist in recording in each ENUM database all of the portability data (e.g. the current network/domain to which the user associated with the telephone number now belongs), or at least those relating to numbers leaving the network under consideration; however such a solution would have considerable impact on the processes of managing portability data (inputting, updating, verifying consistency, etc.), in particular because of the fact that DNS infrastructures managed by distinct operators are de facto separate and compartmentalized: that solution is therefore very difficult to put into practice.
A second solution consists in extending existing ENUM servers so as to incorporate an interface for interrogating the database of number portability history. However such a solution is contrary to DNS logic; in addition, it assumes that there are as many extensions as there are distinct ENUM servers that have been deployed, which would make the network operator highly dependent on its ENUM server suppliers.
The document entitled “IR.67-DNS/ENUM guidelines for service provides & GRW/IPX providers”, published on Aug. 13, 2010 by the “GSM Association”, proposes (cf. in particular Appendix C) considering each ported number as a zone of the naming space delegated to the taking operator. That makes it necessary for each ported number to store records of a particular type referred to as the name server (NS) type in the redirecting server and in the destination server, together with additional zone definition records of the start of authority (SOA) type in the destination server. A first drawback of such an “NS records” solution is that the operators concerned need to agree on a common ENUM root. A second drawback is that it triples the quantity of records stored by the taking operator; and since the industrial licenses of ENUM servers can be proportional to volume, such a solution would be extremely expensive.